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(57) A receiver system (12) automatically adaptively 
tunes (20) to broadcast signals that are variable in the 
number of channels that are transmitted, their signal 
coding type and their modulation format. A system re- 
ceives a digital bitstream representing video information 
encoded in one of a plurality of different formats, and 
transmitted on one of a plurality of transmission chan- 
nels. The system includes a processor 



(17,55,20,25,30,50) for identifying and capturing pro- 
gram guide information including a plurality of channel 
maps. A channel map associates a transmission chan- 
nel with a video channel output and the channel map is 
also associated with an encoding format. The system 
also includes an adaptive decoder (35,40,45) for decod- 
ing the bitstream to provide the video channel output in 
response to the program guide information. 
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Description 

This invention is related to the field of digital signal 
processing, and more particularly to the acquisition and 
processing of video data and Program Guide Informa- 
tion derived from input data encoded in variable broad- 
cast encoding formats. 

Background of the Invention 

In video processing and storage applications, digital 
video data is typically encoded to conform to the require- 
ments of a known standard. One such widely adopted 
standard is the MPEG2 (Moving Pictures Expert Group) 
image encoding standard, hereinafter referred to as the 
"MPEG standard". The MPEG standard is comprised of 
a system encoding section (ISO/IEC 13818-1, 10th 
June 1994) and a video encoding section (ISO/IEC 
13818-2, 20th January 1995), hereinafter referred to as 
the "MPEG systems standard" and "MPEG video stand- 
ard" respectively. Video data encoded to the MPEG 
standard is in the form of a packetized datastream which 
typically includes the data content of many program 
channels (e.g. content corresponding to cable television 
channels 1-125). In order for a decoder to decode the 
packetized datastream and to recover the video data 
content of selected program channels for display, for ex- 
ample, the individual packets that comprise the selected 
program channels must be identified and assembled. 

In order to recover the content of selected program 
channels, information in a Program Guide is used in 
identifying and assembling individual data packets that 
constitute the selected programs. For this purpose Pro- 
gram Guide data is acquired from the program datast- 
ream that is input to a video decoder The Program 
Guide data is formed into a Master Program Guide 
(MPG) sufficient to decode the selected programs. 
Once it is formed, the MPG may be used to decode the 
selected programs or it may be transmitted along with 
the data content of the selected programs to another ap- 
plication device. However, in some video transmission 
systems, it is necessary to acquire and form the MPG 
from Program Guide data encoded in variable broadcast 
encoding formats. 

Variable broadcast encoding formats are used in 
wireless terrestrial video broadcast systems to selec- 
tively provide enhanced levels of broadcast signal noise 
immunity. However, a broadcast encoding format that 
provides enhanced noise immunity also requires in- 
creased transmission bandwidth. An example of a sys- 
tem that uses variable broadcast encoding formats is 
the proprietary Multipoint Microwave Distribution Sys- 
tem (MMDS) which uses a "line-of -sight" transmission 
system. In such a system, an encoding format that pro- 
vides a broadcast signal with a higher degree of immu- 
nity to noise also incurs a higher error correction coding 
overhead and consequently requires greater transmis- 
sion bandwidth. Similarly, for a fixed transmission band- 



width, providing a broadcast signal with a higher degree 
of noise immunity reduces the information throughput 
that may be attained. Further, the encoding format used 
may be varied on a temporal or geographical basis to 
s accommodate variations in reception conditions asso- 
ciated with atmospheric or landscape features. 

The variation in broadcast modulation and error cor- 
rection coding format and the associated required trans- 
mission bandwidth presents problems to a video receiv- 
es er both in decoding the variable encoding formats and 
in acquiring a compatible MPG. These problems are ad- 
dressed by a system according to the present invention. 

The use of variable broadcast encoding formats 
may result in a variation in the transmission bandwidth 
is available for program data content. The inventors have 
hereby recognized that the number of program channels 
that are transmitted using variable broadcast encoding 
formats may be changed in conjunction with encoding 
format. Further, the number of program channels may 
20 be varied both over time : and with geographical broad- 
cast area. 

The inventors have further recognized that it is de- 
sirable for a receiver system to be capable of adaptively 
receiving variable broadcast encoding formats and a 

2S variable number of program channels. This allows the 
signal noise immunity of the broadcast system to be tai- 
lored to the requirements of a particular broadcast area. 
The receiver may be configured to provide higher broad- 
cast signal noise immunity in a particular broadcast area 

^o where reception conditions are impaired due to hilly ter- 
rain, for example. 

A disclosed receiver system automatically adap- 
tively tunes to broadcast signals that are variable in: a) 
the number and the frequency allocation of the channels 

35 that are transmitted, b) the signal coding type e.g. trellis 
or non-trellis coded, and c) the modulation format e.g. 
formats using symbol constellations of 64 or 256 ele- 
ments. 

In accordance with the principles of the present in- 
io vention, a system receives a digital bitstream represent- 
ing video information encoded in one of a plurality of 
different formats, and transmitted on one of a plurality 
of transmission channels. The system includes a proc- 
essor for identifying and capturing program guide infor- 
ms mation including a plurality of channel maps. A channel 
map associates a transmission channel with a video 
channel output, and the channel map is also associated 
with an encoding format. The system also includes an 
adaptive decoder for decoding the bitstream to provide 
so the video channel output in response to the program 
guide information. 

In a feature of the invention, the processor deter- 
mines a transmission channel and broadcast encoding 
format associated with a desired video channel output 
ss from the program guide information and the adaptive de- 
coder provides the desired video channel output in re- 
sponse to the determined format. 
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Brief Description of the Drawings 



In the drawing: 

Figure 1 is a block diagram of apparatus, according 
to the principles of the invention, for demodulating and 
decoding signals of variable broadcast encoding format 
for display. 

Figure 2 shows a flowchart for a process for tuning 
a Forward Error Correcting decoder system to a signal 
of variable broadcast encoding format. 

Figure 3 shows a flowchart for a process for acquir- 
ing a Master Program Guide (MPG) from an input signal 
containing multiple Physical Transmission Channels 
(PTCs). 

Figure 4 shows a flowchart for a process for provid- 
ing selected video channel or program guide information 
for display from an input signal containing multiple Phys- 
ical Transmission Channels (PTCs). 

Figure 5 shows a flowchart for a process for forming 
program guide information and incorporating the pro- 
gram guide information in a video program datastream 
for transmission in variable broadcast encoding formats. 

Figure 1 is a block diagram of a receiver system, 
according to the principles of the invention, for demod- 
ulating and decoding signals of variable broadcast en- 
coding format for display. The receiver system automat- 
ically adaptively tunes to broadcast signals that are var- 
iable in: a) the number and the frequency allocation of 
the channels that are transmitted, b) the signal coding 
type e.g. trellis or non-trellis coded, and c) the modula- 
tion format e.g. formats using symbol constellations of 
64 or 256 elements. Parameters indicative of coding 
type and modulation format are advantageously incor- 
porated in Program Guide information within the trans- 
mitted signals in order to facilitate the receiving and de- 
coding of the variable broadcast encoding formats. 

The ability of the receiver system of Figure 1 to 
adaptively receive variable broadcast encoding formats 
allows the signal noise immunity of the broadcast sys- 
tem to be tailored to the requirements of a particular 
broadcast area. For example, the receiver may be con- 
figured to provide higher broadcast signal noise immu- 
nity in a particular broadcast area where reception con- 
ditions are impaired due to hilly terrain. In such a mode, 
the receiver may be configured for a less noise sensitive 
modulation format e.g. using 64 elements (in preference 
to 256 elements) and trellis coded data, for example. 
However, the enhanced noise immunity encoding re- 
quires greater signal bandwidth which results in less 
bandwidth being available for program data content and 
therefore fewer program channels may be transmitted. 
Consequently, the receiver of Figure 1 also adapts to 
variation in the number and the frequency allocation of 
the channels that are transmitted. 

Although the disclosed system is described in the 
context of a system for receiving variable broadcast en- 
coding format signals that are MPEG compatible, it is 
exemplary only. The principles of the invention may be 
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applied to systems in which the transmission channels 
may vary in number or in frequency allocation, or to sys- 
tems in which the coding type or modulation format may 
be varied. Such systems may include, for example, non- 

5 MPEG compatible systems, involving other types of en- 
coded datastreams and other methods of conveying 
Program Guide information. Further, although the dis- 
closed system is described as processing broadcast 
programs, this is exemplary only. The term 'program' is 

10 used to represent any form of packetized data such as 
telephone messages, computer programs, internet data 
or other communications, for example. 

In overview, in the video receiver system 1 2 of Fig- 
ure 1 , a carrier modulated with video data is received by 

is antenna 1 5 and processed by unit 20. The resultant dig- 
ital output signal is demodulated by demodulator 25. 
The demodulated output from unit 25, optionally differ- 
entially decoded by decoder 30, is provided to unit 50 
via multiplexers (muxes) 35 and 45 following optional 

20 trellis decoding by trellis decoder 40. The optionally trel- 
lis decoded output from mux 45 is mapped into byte 
length data segments, deinterleaved and Reed-Solo- 
mon error corrected by unit 50. The corrected output da- 
ta from unit 50 is processed by MPEG compatible trans- 

25 port processor 55 which separates data according to 
type based on an analysis of header information and 
provides synchronization and error indication informa- 
tion used in subsequent video data decompression. 
Compressed video and audio output data from proces- 

30 sor 55 is decompressed by MPEG decoder 60 to provide 
audio and video output data to audio processor 70 and 
to video processor 65. Processors 65 and 70 format the 
audio and video signals to be suitable for reproduction 
by unit 75. 

35 A video receiver user selects for viewing either a 

video channel or an on-screen menu, such as a program 
guide, by using a remote control unit (not shown to sim- 
plify drawing). System controller 17 uses the selection 
information, provided from the remote control unit, to ap- 

40 propriately configure the elements of Figure 1 to receive, 
demodulate and decode the input signal coding type, 
including differential or non-differential codes, trellis or 
non-trellis codes, and input signal modulation format, in- 
cluding 64 or 256 element symbol constellations. Ele- 

45 ments 20, 25, 30, 40, 50 and 55 of Figure 1 are individ- 
ually configured for the input signal type by setting con- 
trol register values within these elements and by select- 
ing signal paths via muxes 35 and 45 using a bi-direc- 
tional data and control signal bus C. It is to be noted that 

50 the demodulator and decoder functions implemented by 
units 20, 25, 30, 40 and 50 are individually known and 
generally described, for example, in the reference text 
Digital Communication, Lee and Messerschmidt (Kluw- 
er Academic Press, Boston, MA, USA, 1988). 

55 Considering Figure 1 in detail, a carrier modulated 

with video data received by antenna 15, is converted to 
digital form and processed by input processor 20. Proc- 
essor 20 includes radio frequency (RF) tuner and inter- 
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mediate frequency (IF) mixer and amplification stages 
for down-converting the input video signal to a lower fre- 
quency band suitable for further processing. In this ex- 
emplary system, the input signal received by the anten- 
na contains 33 Physical Transmission Channels (PTCs s 
0-32). Each Physical Transmission Channel (PTC) is al- 
located a 6 MHz bandwidth and contains up to 6 video 
channels e.g. corresponding to cable TV channels 2-7. 

It is assumed for exemplary purposes that a video 
receiver user selects a video channel (SC) for viewing w 
using a remote control unit (not shown to simplify draw- 
ing). System controller 1 7 uses the selection information 
provided from the remote control unit to appropriately 
configure the elements of system 1 2 to receive the PTC 
corresponding to the selected video channel SC. Fol- '5 
lowing down conversion, the output signaf from unit 20 
for the selected PTC has a bandwidth of 6 MHz and a 
center frequency in the range of 11 9-405 MHz. 

Controller 17 configures the radio frequency (RF) 
tuner and intermediate frequency (IF) mixer and ampli- 20 
fication stages of unit 20 to receive the selected PTC. 
The down-converted frequency output for the selected 
PTC is demodulated by unit 25. The primary functions 
of demodulator 25 are recovery and tracking of the car- 
rier frequency, recovery of the transmitted data clock f re- 2 $ 
quency, and recovery of the video data itself. 

A carrier recovery loop in unit 25 processes the out- 
put from unit 20 to recover baseband video information. 
The data from unit 20 is a binary datastream represent- 
ing a symbol sequence where each symbol is represent- 30 
ed by assigned digital values. A set of symbols may be 
represented in a complex plane as a set of points called 
a symbol constellation, as known. The variable broad- 
cast signal formats that are input to system 12 use 
Quadrature Amplitude Modulated (QAM) symbol con- 35 
stellations of either 64 or 256 points. The carrier recov- 
ery loop function in unit 25 compensates for symbol 
point offset and symbol point rotation caused by phase 
and frequency jitter in the carrier frequency introduced 
by the transmission channel and the instability of the os- -to 
cillators in the low-noise-block (LNB) downconverter, as 
known. 

The unit 25 carrier recovery loop derives a carrier 
offset value representing the symbol point rotation in- 
duced by the frequency error between the transmitted 
and derived carrier frequency of the selected PTC. The 
derived carrier offset value is used by the unit 25 carrier 
recovery loop to compensate for the symbol rotation in- 
duced by this frequency error. The carrier offset value 
in the exemplary embodiment does not significantly so 
change between different PTCs. Consequently, once 
the carrier offset value is derived for one PTC it is stored 
by controller 1 7 and applied to the unit 25 carrier recov- 
ery loop to expedite the re-tuning of system 12 to other 
PTCs. The time required to retune system 12 to a dif- 55 
ferent PTC is reduced by applying the stored carrier off- 
set value to the unit 25 carrier recovery loop because 
the offset value accelerates recovery loop convergence. 
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In order to compensate for frequency drift and other var- 
iations affecting carrier loop convergence, controller 17 
provides that the carrier offset value is periodically de- 
rived and updated. System 1 2 may alternatively be con- 
figured to derive a carrier offset value specific to each 
PTC for use in carrier recovery loop compensation. 

The unit 25 demodulator also incorporates an 
equalizer function used in conjunction with the carrier 
recovery loop for the purpose of compensating for trans- 
mission channel perturbations and for reducing inter- 
symbol interference, as known. In addition, a sheer in 
unit 25 applies a series of decision thresholds to the cor- 
rected output from the carrier recovery loop to recover 
the symbol sequence of the data that is input to demod- 
ulator 25. The slicer is configured by controller 17 for 
either a 64 point or 256 point QAM symbol constellation 
in response to the configuration Control signal C The 
recovered video data output from unit 25 is provided to 
differential decoder 30. 

Unit 25 also recovers sampling and synchronization 
clocks that correspond to transmitter clocks and are 
used for timing the operation of processor 20, demodu- 
lator 25 and differential decoder 30. The clocks are de- 
rived within unit 25 in accordance with known principles 
by deriving a phase and timing error signal based on a 
comparison of the slicer input and output data. The de- 
rived error signal is filtered and applied to the control 
input of a voltage controlled crystal oscillator to generate 
the clocks. Alternatively, a clock frequency greater than 
twice the symbol rate may be used as a sampling clock. 

The output of demodulator 25 is optionally differen- 
tially decoded by unit 30 and passed to multiplexer 35. 
Differential encoding/decoding is a known technique 
used to overcome the problem associated with potential 
phase ambiguity in the derived carrier and recovered 
symbol constellation. 

Controller 17 determines whether the input data is 
to be trellis decoded from parameters within the input 
data, or arbitrarily selects trellis decoding as part of an 
iterative initialization process. This initialization process 
is used for appropriately configuring system 12 to ac- 
quire and decode the received input data, as discussed 
later in connection with Figure 2. If controller 17 selects 
a trellis decoding mode, either differentially decoded da- 
ta from decoder 30 or demodulated data from unit 25 is 
passed via mux 35 to trellis decoder 40. Decoder 40 ap- 
plies known trellis decoding principles to detect code se- 
quences in trellis encoded data from mux 35. Decoder 
40 determines from the data symbols received from mux 
35 the most likely corresponding sequence of bits that 
would have been trellis encoded by the encoder and 
thereby identifies the corresponding transmitted data 
symbols. The resulting recovered original data is pro- 
vided via mux 45 to unit 50. However, if controller 17 
selects a non-trellis decoding mode, either differentially 
decoded data from decoder 30 or demodulated data 
from unit 25 is provided to unit 50, via muxes 35 and 45, 
bypassing trellis decoder 40. 
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The output from mux 45 is mapped into byte length 
data segments, deinterleaved and Reed-Solomon error 
corrected according to known principles by unit 50. In 
addition, unit 50 provides a Forward Error Correction 
(FEC) validity or lock indication to controller 17 Reed- 
Solomon error correction is a known type of Forward Er- 
ror Correction. The FEC lock indication signals that the 
R eec j-5olomon error correction is synchronized to the 
data being corrected and is providing a valid output 

The corrected output data from unit 50 is processed 
by MPEG compatible transport processor 55. The indi- 
vidual packets that comprise either particular program 
channel content, or Program Guide information, are 
identified by their Packet Identifiers (PIDs). Processor 
55 separates data according to type based on an anal- 
ysis of Packet Identifiers (PIDs) contained within header 
information and provides synchronization and error in- 
dication information used in subsequent video data de- 
compression. 

Individual packets that comprise a selected pro- 
gram channel are identified and assembled using PIDs 
contained in a Master Program Guide (MPG). However, 
the PIDs identifying the MPG packets are predeter- 
mined and stored in internal memory of controller 17. 
Therefore, after controller 17 determines from the FEC 
lock indication provided by unit 50 that system 12 is pro- 
ducing valid data to transport processor 55, the MPG 
which is present on every PTC may be acquired without 
additional PID information. Using Control signal C, con- 
troller 1 7 configures transport processor 55 to select the 
data packets comprising the MPG. Processor 55 match- 
es the PIDs of incoming packets provided by mux 45 
with PID values pre-loaded in control registers within 
unit 55 by controller 17. Controller 17 acquires a full 
MPG by accessing and assembling the MPG packets 
that are identified and captured by processor 55. 

The information in the MPG that enables controller 
17, in conjunction with processor 55, to identify data 
packets that comprise individual programs, is termed a 
channel map. Further, the MPG advantageously con- 
tains channel map information that permits identification 
of packets comprising individual programs for all the 
PTCs and for the different broadcast encoding formats. 
Different channel mappings are associated with differ- 
ent broadcast encoding formats because the maximum 
number of available Physical Transmission Channels 
(PTCs) is determined by the available transmission 
bandwidth for a particular encoding format. As previous- 
ly explained, the use of an encoding format that provides 
greater signal noise immunity results in less bandwidth 
being available for program content transmission. The 
channel mappings may also be varied to allow variation 
in transmitted program content between different broad- 
cast areas or to allow change, i.e., addition or deletion 
of services, in normal broadcast operations. 

Controller 17 uses the channel map information in 
the acquired MPG to identify the packets comprising the 
video channel SC that the User selected to view. Proc- 



essor 55 matches the PIDs of incoming packets provid- 
ed by mux 45 with PID values of video channel SC pre- 
loaded in control registers within unit 55 by controller 
17. In this manner, processor 55 captures video channel 
s SC packets and forms them into an MPEG compatible 
datastream containing compressed video and audio da- 
ta representing the selected video channel SC program 
content. 

The compressed video and audio output data from 

w processor 55 is decompressed by MPEG decoder 60 to 
provide audio and video output data to audio processor 
70 and to video processor 65. Processors 65 and 70 
format the audio and video signals to be suitable for re- 
production by unit 75. It is to be noted that the MPEG 

15 compatible datastream incorporating the MPG output by 
processor 55 may alternatively be provided to a storage 
device for storage (not shown to simplify drawing). 

Controller 17 employs the process of Figure 2 for 
tuning and configuring processor 20, demodulator 25, 

20 differential decoder 30 and trellis decoder 40 to receive 
a signal of variable broadcast encoding format, as pre- 
viously discussed in connection with Figure 1 The proc- 
ess of Figure 2 automatically adaptivefy tunes system 
12 to receive signals that are variable in: a) the number 

25 and the frequency allocation of the channels that are 
transmitted, b) the signal coding type e.g. trellis or non- 
trellis coded, or differential or non-differential coded, 
and c) the modulation format e.g. modulation formats 
using symbol constellations of 64 or 256 elements. The 

30 process of Figure 2 is used when the FEC lock indication 
provided by unit 50 (Figure 1) signals that lock has not 
been achieved. Such a condition may occur at a first 
time power-up or following a broadcast encoding format 
change at the encoder, for example. In the exemplary 

35 process of Figure 2, the input data to system 1 2 is either 
both differentially coded and trellis coded, or it is neither 
differentially coded nor trellis coded. 

Following the start at step 100 of Figure 2, a carrier 
offset value is derived in step 105 in the manner previ- 

40 ously described in connection with Figure 1 . The carrier 
offset value is derived for an initial PTC e.g. PTC=0, and 
applied by controller 17 in step 105 to the unit 25 carrier 
recovery loop. In step 110, controller 17 is programmed 
to iteratively execute process steps 115-150 of Figure 2 

45 for each PTC, beginning with the first PTC (PTC=0) until 
FEC lock to one of the PTCs has been achieved. 

In step 115, controller 17 configures demodulator 
25 for a 64 QAM modulation format symbol constellation 
and configures muxes 35 and 45 to provide the output 
50 from demodulator 25 to unit 50 bypassing decoder 30 
and trellis decoder 40. If controller 1 7 determines in step 
120 that FEC lock has not been achieved by unit 50, 
controller 17 performs step 125 to configure demodula- 
tor 25 for a 64 QAM modulation format. In addition, con- 
55 troller 1 7 in step 1 25, configures decoder 30 and decod- 
er 40 to differentially decode and trellis decode the out- 
put data from demodulator 25 to provide differentially 
decoded and trellis decoded data to unit 50 via muxes 
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35 and 45. 

If controller 1 7 determines in step 1 30 that FEC lock 
has not been achieved by unit 50, controller 1 7 performs 
step 135 to configure demodulator 25 for a 256 QAM 
modulation format symbol constellation. Also controller 
17, in step 135, configures muxes 35 and 45 to provide 
output data from demodulator 25 to unit 50 bypassing 
decoder 30 and trellis decoder 40. If controller 1 7 deter- 
mines in step 140 that FEC lock has not been achieved 
by unit 50, controller 17 performs step 145 to configure 
demodulator 25 for a 256 QAM modulation format. In 
addition, controller 17 in step 145 : configures decoder 
30 and decoder 40 to differentially decode and trellis de- 
code the output data from demodulator 25 to provide 
differentially decoded and trellis decoded data to unit 50 
via muxes 35 and 45. 

If controller 17 in step 150 determines that unit 50 
has not achieved FEC lock after iterating through steps 
115-150 for each of the PTCs (PTCs 0-32), controller 
17, in step 155, provides an indication of system error 
to the User. This may take the form of a panel light indi- 
cation, or a default picture display on reproduction ap- 
paratus 75, or an error message conveyed by a tele- 
phone line or another type of fault indication. However 
if unit 50 achieves FEC lock for any of the PTCs in steps 
120, 130, 140 or 150, controller 17 performs step 160. 
In step 160, controller 17 stores in its internal memory 
the carrier offset value, the modulation format (either 64 
or 256 QAM) and the coding type (either trellis or non- 
trellis coded) for the PTC for which FEC lock was ac- 
quired. Following completion of steps 155 or 160 the 
process of Figure 2 terminates at step 165. 

Controller 1 7 employs the process of Figure 3 to ac- 
quire a Master Program Guide (MPG) from an input sig- 
nal containing multiple Physical Transmission Channels 
(PTCs). The process of Figure 3 is used following the 
Figure 2 process for tuning system 12 to a particular 
PTC. However, the process of Figure 3 may also be em- 
ployed whenever acquisition of a new MPG is desired 
such as following a broadcast encoding format change 
at an encoder. 

Following the start at step 200 of Figure 3, controller 
17 searches the data output from mux 45 (Figure 1 ) for 
MPG data packets. As previously discussed in connec- 
tion with Figure 1, controller 17, in step 205, pre-loads 
internal registers within processor 55 with the MPG PID 
values. Processor 55 matches the MPG PID values 
against the PID values of the data packets input from 
mux 45 and captures the identified MPG data packets. 
Following detection of MPG data packets in step 210, 
controller 17, in step 240, transfers the MPG packets 
captured by processor 55 into internal memory. Control- 
ler 17 continues the step 240 process until a full, valid 
and error free MPG has been acquired decoded, and 
assembled in internal memory. If controller 17 deter- 
mines, in step 245, that a full, valid and error free MPG 
has been acquired, execution of the Figure 3 process is 
complete and terminates at step 260. 



If controller 17 determines, in step 245, that a full, 
valid and error free MPG has not been acquired control- 
ler 17 configures system 12 (Figure 1) to receive the 
next PTC in step 215, e.g. PTC number 1 if the current 

s PTC is zero. Also, if MPG data packets are not detected 
by processor 55 in step 210, controller 17 similarly con- 
figures system 12 to receive the next PTC in step 215. 
However, if controller 17 determines, in step 220, that 
all available PTCs have been searched without suc- 

w cess, controller 1 7 indicates a system error to the User 
in step 230. This may take the form of a panel light in- 
dication, or a default picture display on reproduction ap- 
paratus 75, or an error message conveyed by a tele- 
phone line or another type of fault indication. 

is if controller 1 7 determines, in step 220, that all avail- 
able PTCs have not been searched, controller 17, in 
step 225, performs the previously described tuning 
process of Figure 2 from step 1 1 5 (Figure 2) for the PTC 
selected in step 215 (Figure 3). This portion of the proc- 

20 ess of Figure 2 is used to tune system 12 to the PTC 
selected in step 215 (Figure 3). After tuning system 12 
to the new PTC in step 225, controller 17 repeats the 
Figure 3 process for acquiring a MPG beginning with 
step 205. Execution of the Figure 3 process is complete 

25 and terminates at step 260 after either the generation of 
an error indication in step 230, or after step 245 and the 
successful acquisition of a MPG. 

Controller 17 employs the process of Figure 4 to 
provide selected video channel or program guide infor- 

30 mation for display from an input signal containing mul- 
tiple Physical Transmission Channels (PTCs) and vari- 
able modulation and coding formats. The process of Fig- 
ure 4 is used following the acquisition of a MPG by the 
process of Figure 3, for example. 

35 Following the start at step 300 of Figure 4, controller 
17, in step 305; determines from selection information 
provided from a remote control unit whether a User has 
requested a video channel or a program guide for view- 
ing. If a video channel (SC) has been selected, controller 

JO 17 in step 310, determines on which PTC the selected 
channel SC is transmitted using previously stored MPG 
information. In step 315 controller 1 7 determines wheth- 
er the PTC of the selected channel is different from the 
PTC to which system 12 is presently tuned. If the PTC 

•*5 of the selected channel is different from the present 
PTC, controller 17, in step 320, configures system 12 
with the carrier offset value, modulation format (either 
64 or 256 QAM) and the coding type (either trellis or non- 
trellis coding) of the required PTC. The modulation tor- 
so mat and the coding type of the required PTC are deter- 
mined by controller 1 7 from parameters within the stored 
MPG data. The carrier offset value for the required PTC 
is obtained by controller 17 from stored offset data pre- 
viously determined in the acquisition process of Figure 

55 2. 

In step 325, controller 17 performs the previously 
described tuning process of Figure 2 from step 115 (Fig- 
ure 2). This portion of the process of Figure 2 is used to 
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tune system 12 to the PTC that was determined in step 
31 0 (Figure 3) and on which the selected video channel 
SC is transmitted. However, in step 31 5 : if the PTC of 
the selected video channel SC is the same as the PTC 
to which system 12 is presently tuned, controller 17 by- 
passes step 320-325 and continues the process with 
step 330. 

In step 330. controller 17 uses MPG data to identify 
the packets comprising the video channel SC that the 
User selected to view. As described in connection with 
Figure 1, processor 55 matches the PIDs of incoming 
packets provided by mux 45 with PID values of video 
channel SC pre-loaded in control registers within unit 55 
by controller 17. In this manner, processor 55 in step 
335, governed by controller 17, captures video channel 
SC packets and forms them into an MPEG compatible 
datastream containing compressed video and audio da- 
ta representing the selected video channel SC program 
content. 

I n step 365, the compressed video and audio output 
data from processor 55, as directed by controller 17, is 
decompressed by MPEG decoder 60 to provide audio 
and video output data to audio processor 70 and to video 
processor 65. In addition, in step 365, processors 65 
and 70 format the audio and video signals to be suitable 
for reproduction by unit 75. The Figure 4 process termi- 
nates at step 370 

However if in step 305 a program guide is request- 
ed for viewing by the video receiver User, controller 17 
in step 350 determines whether a Special Program 
Guide (SPG) or a MPG has been requested. The MPG 
is transmitted on every PTC and contains all the infor- 
mation required to identify and assemble packets that 
comprise a selected video channel program or an SPG. 
In contrast, a SPG is an optional guide and may be 
transmitted on only a limited number of the PTCs e.g. 
PTC=0. Further, there may be several different SPGs 
and an individual SPG may contain information on only 
selected video channels. 

In the exemplary process of Figure 4, an SPG is 
transmitted on PTC zero. Therefore, if in step 350 a SPG 
is requested for viewing, controller 17 in step 360 sets 
the required PTC as zero and continues execution of 
the Figure 4 process from step 315 in the manner pre- 
viously described. However, if in step 350 a MPG is re- 
quested for viewing, controller 17 in step 355 retrieves 
the MPG data previously stored in internal memory and 
in conjunction with processor 55, forms an MPG repre- 
sentative datastream. The resultant MPG representa- 
tive datastream provided by processor 55 is an MPEG 
compatible datastream containing compressed video 
and audio data. In step 365, the compressed video and 
audio output data from processor 55 is decompressed 
by MPEG decoder 60 to provide audio and video output 
data to audio processor 70 and to video processor 65. 
In addition, in step 365, processors 65 and 70 format 
the audio and video signals to be suitable for reproduc- 
tion by unit 75. The Figure 4 process terminates at step 



370. 

The principles of the invention also apply to the for- 
mation, encoding and transmission of a datastream in- 
corporating a MPG as described herein. The invention 

5 principles apply to the formation of a MPG incorporating 
channel map information that permits identification of 
packets comprising individual programs for ail the PTCs 
and for the different broadcast encoding formats. The 
invention principles similarly apply to the formation of a 

10 MPG incorporating parameters indicative of modulation 
format and coding type. 

A datastream formed according to the invention 
principles may be used for communication in a variety 
of applications including video server or PC type com- 

is munication via telephone lines, for example. A video 
program datastream formed to incorporate a MPG ac- 
cording to invention principles may be recorded on a 
storage medium and transmitted or re-broadcast to oth- 
er servers, PCs or receivers. Further, a video program 

20 may be stored in trellis coded or non-trellis coded form, 
for example. 

If a program is stored in trellis coded form, the 
stored program guide information including modulation 
and coding type data, facilitates demodulation and de- 
25 coding of the program by subsequent receivers upon re- 
trieval and re-broadcast of the program. If a program is 
stored in non-trellis coded form, upon retrieving the pro- 
gram from a storage medium, a server may modulate 
and trellis encode the program in accordance with the 

30 modulation and coding type data conveyed in the pro- 
gram guide. The program may then be re-transmitted to 
other receivers which may use the modulation and cod- 
ing type data in the program guide information to facili- 
tate demodulation and decoding of the program. Simi- 

35 larly, in such a video server type application involving 
re -broadcast of programs, a server may re-modulate the 
program data for transmission in accordance with pro- 
gram guide information. 

Figure 5 shows a flowchart for a process for forming 

io program guide information and incorporating the pro- 
gram guide information in a video program datastream 
for transmission in variable broadcast encoding formats. 
Following the start at step 400 of Figure 5, parameters 
are generated in step 405 indicating the modulation for- 

15 mat and coding type to be used for transmission of each 
of the PTCs. In step 410, channel maps are generated 
identifying data packets that comprise individual video 
programs and their accompanying audio data that are 
to be transmitted on each of the PTCs. In step 415, the 

50 modulation format and coding type indication parame- 
ters, generated in step 405, are incorporated within the 
channel maps, thereby associating a PTC with a partic- 
ular broadcast encoding format and particular video pro- 
grams. The program guide format may be of a variety 

55 of types. For example, it may be comply with Program 
Specific Information (PSI) requirements specified in 
section 2.4.4 of the MPEG systems standard or it may 
comply with the high definition television (HDTV) signal 
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standard Digital Television Standard for HDTV Trans- 
mission of April 12 1995, prepared by the United States 
Advanced Television Systems Committee (ATSC). Al- 
ternatively, it may be formed in accordance with propri- 
etary or custom requirements of a particular system. s 

In step 420, program guide information is formed 
incorporating the channel maps and modulation format 
and coding type parameters. The program guide infor- 
mation is incorporated into a selected video program da- 
tastream in step 425 to form a video output program In to 
step 430 ; the video output program data is further proc- 
essed to be suitable for transmission to another device 
such as a receiver video server, or storage device for 
recording on a storage medium, for example. The proc- 
esses performed in step 430 includes known encoding 1$ 
functions such as data compression Reed-Solomon en- 
coding, interleaving, scrambling, optional trellis encod- 
ing, differential encoding and modulation. The process 
is complete and terminates at step 435. 

The architecture of Figure 1 is not exclusive. Other 20 
architectures may be derived in accordance with the 
principles of the invention to accomplish the same ob- 
jectives. Further, the functions of the elements of system 
12 of Figure 1 and the process steps of Figure 2-5 may 
be implemented in whole or in part within the pro- 25 
grammed instructions of a microprocessor. In addition, 
the principles of the invention apply to any form of MPEG 
or non-MPEG compatible electronic program guide. 
Further, although the disclosed system receives varia- 
ble broadcast QAM modulation formats and trellis or 30 
non-trellis coded data, it is exemplary only. The princi- 
ples of the invention may be applied to systems that re- 
ceives other types of signal coding, not just optional trel- 
lis coding and other modulation formats not just QAM 
including forms of Pulse Amplitude Modulation (PAM). 35 

Claims 

1. In a system for receiving a digital bitstream repre- -to 
senting video information encoded in one of a plu- 
rality of different formats, and transmitted on one of 

a plurality of transmission channels, apparatus 
comprising: 

45 

a processor (17,20,25,30,50,55) responsive to 
said bitstream for capturing program guide in- 
formation including a plurality of channel maps, 
wherein a channel map associates a transmis- 
sion channel with a video channel output and so 
said channel map is associated with an encod- 
ing format: and 

an adaptive decoder (35,40,45) for decoding 
said bitstream to provide said video channel 
output in response to said program guide infor- 55 
mation. 

2. Apparatus according to claim 1 , wherein 
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said program guide information is transmitted 
on a plurality of said transmission channels. 

3. Apparatus according to claim 1 , wherein 

said channel maps include a first channel map 
associating a first number of transmission channels 
with a first encoding format and a second channel 
map associating a different second number of trans- 
mission channels with a second encoding format. 

4. Apparatus according to claim 4, wherein 

said first channel map transmission channels 
have a different frequency allocation compared to 
said second channel map transmission channels. 

5. Apparatus according to claim 1, wherein 

said program guide information includes a pa- 
rameter indicative of coding type; and 
said adaptive decoder is configured in re- 
sponse to said parameter. 

6. Apparatus according to claim 1 , wherein 

said program guide information includes a pa- 
rameter indicative of modulation format: and 
said adaptive decoder is configured in re- 
sponse to said parameter. 

7. Apparatus according to claim 1 , wherein 

said adaptive decoder is configured with a first 
carrier offset value associated with a first transmis- 
sion channel and a different second carrier offset 
value associated with a second transmission chan- 
nel in response to said program guide information. 

8. In a system for receiving a digital bitstream repre- 
senting video information encoded in one of a plu- 
rality of different formats, and transmitted on one of 
a plurality of transmission channels, apparatus 
comprising: 

a processor (17,20.25,30,50,55) for capturing 
program guide information to determine a 
transmission channel and broadcast encoding 
format associated with a desired video channel 
output: and 

an adaptive decoder (35,40,45) for decoding 
said bitstream to provide said desired video 
channel output in response to said determined 
broadcast encoding format. 

9. Apparatus according to claim 8, wherein 

said adaptive decoder is configured to decode 
said determined broadcast encoding format in re- 
sponse to a broadcast encoding format indicating 
parameter in said program guide information. 
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10. Apparatus according to claim 5 or claim 9, wherein 

said decoder is configured for trellis or non- 
trellis decoding in response to said indicator. 

1 1 . Apparatus according to claim 5 or claim 9, wherein 

said decoder is configured for error correction 
decoding in response to said indicator. 

12. Apparatus according to claim 6 or claim 9, wherein 

said decoder is configured for decoding mod- 
ulation format symbol constellation size in response 
to said indicator. 

13. Apparatus according to claim 1 or claim 8, wherein 

said adaptive decoder is configured with a 
transmission channel dependent carrier offset val- 
ue. 

14. Apparatus according to claim 1 or claim 8, wherein 

said video channel output is selected from a 
plurality of video channel outputs transmitted on 
said transmission channel. 

15. Apparatus according to claim 8, wherein said proc- 
essor, 

tunes to receive said transmission channel en- 
coding format; and 

captures data packets comprising said desired 
video channel output. 

16. Apparatus according to claim 15, wherein 

said processor tunes to receive a coding type 
in response to said program guide information. 

17. Apparatus according to claim 16, wherein 

said coding type includes trellis or non-trellis 
coding. 

18. Apparatus according to claim 16, wherein 

said coding type includes error correction 
coding. 

19. Apparatus according to claim 15, wherein 

said processor tunes to receive a modulation 
format in response to said program guide informa- 
tion. 

20. Apparatus according to claim 19, wherein 

said processor tunes to receive a modulation 
format symbol constellation size in response to said 
program guide information. 

21. Apparatus according to claim 15, wherein 

said processor identifies data packets com- 
prising said desired video channel output using said 
program guide information. 



22. Apparatus according to claim 15, wherein 

said processor selects said video channel 
output from a plurality of video channel outputs 
transmitted on said transmission channel. 

s 

23. Apparatus according to claim 15, wherein 

said processor determines said transmission 
channel from a channel map associating transmis- 
sion channels with an encoding format. 

10 

24. Apparatus according to claim 15, wherein 

said processor configures a demodulator. 

25. Apparatus according to claim 15, wherein 
15 said processor configures a decoder. 

26. A method for decoding a digital bitstream represent- 
ing video information encoded in one of a plurality 
of different formats, and transmitted on one of a plu- 

20 rality of transmission channels, comprising the 
steps of: 

identifying program guide information including 
a plurality of channel maps wherein 
25 a channel map associates a transmission 

channel with a video channel output and said 
channel map is associated with an encoding 
format: 

capturing said program guide information: and 
30 adaptively decoding said bitstream to provide 

said video channel output in response to said 
program guide information. 

27. A method for decoding a digital bitstream represent- 
35 ing video information encoded in one of a plurality 

of different formats, and transmitted on one of a plu- 
rality of transmission channels, comprising the 
steps of: 

40 capturing program guide information: 

determining a transmission channel and broad- 
cast encoding format associated with a desired 
video channel output from said program guide 
information: and 

45 adaptively decoding said bitstream to provide 

said desired video channel output in response 
to said determined broadcast encoding format. 
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